[アップデート] S3 バケットポリシー変更前に IAM Access Analyzer による「外部アクセス許可の検証」ができるようになりました！

S3 バケットポリシーを変更する前に毎回「プレビュー」を押しましょう。

#IAM Access Analyzer

#Amazon S3

#AWS IAM

#AWS

千葉幸宏（チバユキ）

2021.03.11

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

コンバンハ、千葉（幸）です。

IAM Access Analyzer が、対象リソースのパーミッション変更前の事前検証に対応しました！

IAM Access Analyzer now enables you to validate public and cross-account access before deploying permissions changes

これまでは変更後のリソースに対して自動的に分析を行う、という挙動でしたが、変更前のプレビューとしても確認ができるようになりました。

何が変わったのか

IAM Access Analyzer による分析を、対象リソースのパーミッション変更前のタイミングで実施できるようになりました。

対象が S3 バケットの場合、S3 コンソールから確認できます。

IAM Access Analyzer とは

IAM Access Analyzer は、 AWS リソースのリソースベースポリシーを参照し、外部エンティティからアクセス可能な状態になっていないかを確認できるサービスです。

「信頼ゾーン」と呼ばれるゾーンを定義し、その外部からのアクセスが可能な状態を確認すると、検知が行われます。

信頼ゾーンは多くの場合「自身の AWS アカウント」であり、Organizations と連携させた場合には「Organizations 全体」とすることもできます。

AWS-IAM-Access-Analyzer-1

分析（スキャン、検証）対象としてサポートされている AWS リソースは以下です。

S3 バケット
IAM ロール
KMS キー
Lambda 関数とレイヤー
SQS キュー
Secrets Manager シークレット

詳細は以下を参照してください。

Using AWS IAM Access Analyzer - AWS Identity and Access Management

IAM Access Analyzer によるスキャンのタイミング

これまでは以下のタイミングでスキャンが可能でした。

アナライザー作成時のすべての対象リソースに対するスキャン
定期スキャン（24時間以内の間隔）
手動での再スキャン（検知済みのリソースが対象）
検知済みのリソースの変更、もしくは新規リソースの作成をトリガーとするスキャン（30分以内。稀に例外あり）

いずれも、リソースのパーミッション変更後、つまりはすでに設定されているものに対するスキャンです。

比較的短時間で検出できるものの、誤って想定外の外部アクセス許可を与えてしまった場合、検出までは無防備な状態が続くことになります。

今回のアップデートにより事前の検証が可能となったため、きちんと変更による影響を理解した上でパーミッション変更を行えるようになりました。

IAM Access Analyzer による事前の検証

以下のパターンがサポートされています。

S3 コンソールでの確認
- S3 バケットでのみ対応
Access Analyzer API による確認
- 以下で対応
  - S3 バケット
  - IAM ロール
  - KMS キー
  - SQS キュー
  - Secrets Manager シークレット

それぞれドキュメントはこちら。

後者の Access Analyzer API による確認では、以下 API を使用するとドキュメントに記載されています。

CreateAccessPreview
ListAccessPreviewFindings

新しい API がサポートされた際にはそれに対応する AWS CLI コマンドが追加されることが多いのですが、2021/3/11現在ではまだ確認できませんでした。

% aws --version
aws-cli/2.1.30 Python/3.8.8 Darwin/19.6.0 exe/x86_64 prompt/off

% aws accessanalyzer
apply-archive-rule       delete-archive-rule      get-finding              list-findings            untag-resource
create-analyzer          get-analyzed-resource    list-analyzed-resources  list-tags-for-resource   update-archive-rule
create-archive-rule      get-analyzer             list-analyzers           start-resource-scan      update-findings
delete-analyzer          get-archive-rule         list-archive-rules       tag-resource

参考にできる情報が少なかったので、本エントリではこちらのパターンを実際に試すのは見送ります。

やってみた（S3コンソールでのプレビュー）

S3 コンソールでバケットポリシーを変更する際にどのように変わったのか、確認してみます。なお、事前に Access Analyzer がセットアップ済みであることを前提とします。

バケットポリシーの変更画面から、以下のようなポリシーを入力してみます。

S3_Management_Console-5424800

S3 バケットが存在する AWS アカウントとは別の番号を指定しており、クロスアカウントでのアクセス許可を与える内容です。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": "s3:*",
      "Effect": "Allow",
      "Resource": "arn:aws:s3:::cm-chiba-hogehoge",
      "Principal": {
        "AWS": [
          "000000000000"
        ]
      }
    }
  ]
}

ポリシーの入力画面の下部に、新たに外部アクセスをプレビューという項目が追加されています。

[プレビュー] を押下します。

S3_Management_Console-5422178

アナライザーによるスキャンが開始され、以下のように検出結果が表示されます。

外部プリンシパルに対してアクセス許可が与えられている、ということが分かります。（今回は「アクセスレベル」の項目が膨大な数にのぼったので、下部は省略します。）

S3_Management_Console-5422232

プレビュー画面で確認できるのはここまでです。アクセスが意図した通りのものであれば、通常通りバケットポリシーの保存を実行しましょう。

外部アクセスを除外するパターン

上記のバケットポリシーを保存した後、再度バケットポリシーを修正します。

バケットポリシーを空にして再度「プレビュー」を実行すると、解決済みとして検出されました。

S3_Management_Console-5422773

バケットポリシー変更による影響がどんなものかを理解するためにも、都度プレビューは実施したいですね。

パブリックを検知するパターン

以下のポリシーをセットして確認してみます。パブリックな読み書きを許可する設定なので、避けるべきものです。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:*",
            "Resource": "arn:aws:s3:::cm-chiba-hogehoge"
        }
    ]
}

プレビューでは、「パブリック」というバッジがついて検出されます。